The present invention relates generally to class versioning, and, more particularly, to class versioning in an OSGi-enabled J2EE environment.
Java and all Java-based marks are a trademark or registered trademark of Oracle Corporation. Java language is run on a java virtual machine (JVM). A Java program is composed of many individual class files, each of which may correspond to a single Java class. These class files are not loaded into memory all at once but are loaded on demand, as needed by a program. A classloader is the part of the JVM that loads classes into memory.
Java 2 Platform Enterprise Editon (J2EE) is a platform-independent, Java-centric environment from Sun for developing, building and deploying Web-base enterprise applications online. The J2EE platform includes set of services, APIs, and protocols that provide the functionality for developing multitiered, web-based applications.
A J2EE application server may provide a classloader hierarchy, as shown in FIG.1. In this hierarchy, there are three levels: the application classloader level 110, the application server classloader level 120, and the JVM classloader level 130. The application server runtime and extensions may be packaged in Open Service Gateway initiative (OSGi) bundles. The middle level, the application server classloader level 120, may contain a network of classloadrs, one classloader per OSGi bundle. The server provides an application classloader per application at the application classloader level 110.
A problem arises when an application server uses an OSGi classloading implementation that does not natively support class versioning. As explained above, an OSGi implementation in a J2EE environment includes bundles, each with a single associated classloader. An export mechanism packages visible outside a given bundle and a companion mechanism exists for declaring a dependency on another bundle (to use the other bundle exported packages). With the conventional classloader hierarchy there is no way to choose between different versions of a class loaded at the applications server classloader level. This becomes a problem when applications and other portions of the application server runtime require different versions of code from the application server runtime and its extensions. This presents a problem for the application developer, as he or she must solve the class versioning problem. This is an inefficient and time-consumming process. Thus, there exists a need for a technique for enabling a choice between class versions in an OSGI-enabled J2EE environnment.